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HYBRID DATA TRANSPORT SCHEME OVER OPTICAL NETWORKS 

Cross Reference to Related Applications 

This application claims the benefit of U.S. Provisional 
Application No. 60/184,264, filed February 23, 2000, which is 
hereby incorporated by reference in its entirety. 

The present application may relate to U.S. Serial No. 
09/523,576, filed March 10 , 2000, U.S. Serial No. 09/523,476, filed 
March 10, 2000, U.S. Serial No. 09/535,717, filed March 27, 2000, 
U.S. Serial No. 09/535,889, filed March 27, 2000 and U.S. Serial 
No. 09/535,890, filed March 27, 2000, which are hereby incorporated 
by reference in their entirety. 

Field of the Invention 

The present invention relates to a method and/or 
architecture for data transport generally and, more particularly, 
to a method and/or architecture for hybrid data transport over 
optical networks. 
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Background of the Invention 

Conventional SONET/SDH networks are designed to 
efficiently carry transporting plesiochronous digital hierarchy 
(PDH) channels (T1/T3 channels) . In order to support PDH data, 
5 the SONET/SDH frames typically have a payload that is divided into 
fixed timeslots called virtual tributaries (VT) . In keeping with 
timing of the smallest of telephony components DSO (64Kbps) , the 
p SONET/SDH frames are of fixed length repeated at an interval of 

m 125VIS. 

^10 At the rate of 125]iS, each byte of the SONET/SDH frame 

z: represents a basic telephony channel of DSO. The SONET/SDH frames 

q reserve bytes to form higher-order the plesiochronous digital 

M 8 hierarchy (PDH) channels. For example, a Tl channel comprises 28 

M DSO channels. However, growth of Internet traffic and VoIP 

Q 

15 applications requires more data traffic such as internet protocol 
(IP) in addition to standard PDH channels. The IP traffic is being 
carried on the SONET/SDH network in addition to conventional T1/T3 
channels. 

However, the SONET/SDH frame payload areas can only 
20 transport one type of data. A path signal label (PSL) value in 
path overhead (POH) bytes of the SONET/SDH frame typically 
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identifies the type of data contained in the payload area. 
Transporting different data types on a single optical fiber 
requires complex mapping mechanisms. 

Referring to FIG. 1, a conventional approach for 
transmitting data packets on fixed bandwidth virtual tributaries 

(VTs) 10 is shown. The conventional approach 10 comprises a number 
of SONET/SDH frames 12a- 12n. Each of the SONET/SDH frames 
comprises a number of VTs 14a-14n. The virtual tributaries 14a-14n 
comprise a SONET/SDH synchronous payload envelope (SPE) . Each of 
the SPEs can dedicate a portion of bandwidth (a number of the VTs 
14a-14n) to store a particular data type. The unused bandwidth 

(the remaining VTs 14a- 14n) can be used to transport asynchronous 
transfer mode (ATM) or internet protocol (IP) data traffic. 
However, due to the bursty nature of the ATM and IP data traffic, 
allocating a fixed bandwidth (a number of virtual tributaries 14a- 
14n) for the data traffic results in highly inefficient usage of 
available SONET/SDH bandwidth. For purely data-oriented high 
bandwidth applications, the entire SONET/SDH payload (the VTs 14a- 
14n) is commonly used for transporting data bytes (ATM or IP 
packets) . 
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Each frame 12a-12n comprises a path over-head (POH) 16. 
The path over-head 16 comprises an unique path signal label (PSL) 
value 18 that identifies the type of data being carried inside the 
SPE area 14a-14n. 

Referring to FIG. 2, a conventional long-haul multi- 
service access network 3 0 is shown. The network 3 0 comprises a 
number of rings 32a-32ny a first number of add multiplexers 34a- 
34n, a first number of drop multiplexers 36a-36n, a second number 
of add multiplexers 38a-38n and a second number of drop 
multiplexers 40a-40n. The multiplexers 34, 36, 38 and 40 must 
generally be capable of processing different data types (as shown 
in FIG. 3). The optical rings 32a-32n are optical carrier rings. 
The network 3 0 implements the optical rings 32a- 32n transport IP 
and Tl data. The conventional network 3 0 implements a separate 
ring 32a-32n for each consumer, enterprise and metropolitan area 
network. The separate SONET/SDH rings 32a-32n are implemented to 
carry IP data using packet-over-sonet (POS) , ATM, and Tl channels. 

The rings 32b and 32d are local central office (CO) 
rings. The ring 32c is an interexchange ring. The central office 
and interexchange rings 32a-32d are time-division multiplexed 
(TDM) . The time slots (virtual tributaries VTs) are dedicated to 
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the smaller bandwidth rings 32a, 32e, 32f and 32g carrying POS, 
ATM, or T1/T3 traffic. 

A point-to-point cross-connect is established through the 
time slots, allowing long-haul connectivity across the SONET/SDH 
network 30. However, provisioning long-haul transfer of data is a 
time consuming process and requires coordination across many links. 
For example, in order to transfer POS traffic from the ring A (32a) 
to the ring F (32f ) , the POS traffic has to travel through one or 
more time slots of the ring B (32b) , then through similar channels 
at the ring C (32c) , through the ring (32e) E and then to the ring 
F (32f ) . 

Referring to FIG. 3, various types of conventional 
SONET/SDH add/drop devices 50a-50n are shown. The SONET/SDH 
add/drop devices 50a-50n are required at each node (ring 32a-32n) 
on the optical network 30. The add/drop devices 50a-50n are 
required to add and drop traffic to and from the network 30. The 
SONET/SDH add/drop devices 50a-50n illustrate different types of 
SONET/SDH add/drop multiplexers (ADM) . The ADMs 50a-50n are 
attached to the SONET/SDH rings 32a-32n carrying data traffic 
(similar to the devices 34, 36, 38 and 40 of FIG. 2) . 
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The device 50a is a terminal multiplexer. The device 50b 
is a SONET/SDH ADM. The SONET/SDH add/drop devices 50a and 50b are 
designed to add/drop telephony and PDH fixed bandwidth channels 
such as NxDSO (64kbps, carrying a telephony channel) and T1/T3 
channels. The device 50c is a data-aware SONET/SDH ADM. The data- 
aware SONET/SDH ADM 50c is configured to add/drop IP and ATM packet 
data to and from the SONET/SDH rings 32a-32n. The device 50n is a 
digital cross-connect (DCC) . The digital cross-connect (DCC) 50n 
connects different SONET/SDH rings or perform add/drop operations 
on DS3 (45Mbps) channels. 

The conventional network 30 requires multiple data type 
SONET/SDH rings and add/drop devices. The SONET/ SDH network 30 
requires many different fiber rings and different types of add/drop 
devices for creating a medium- to-long haul optical network. The 
multiple SONET/SDH rings and add/drop devices increase cost. 
Additionally, complexity and cost of the SONET/SDH ADMs prohibit 
wide-area deployment for transportation of voice, data, and video 
traffic for long-haul networks. 
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Summary of the Invention 

The present invention concerns an apparatus comprising 
one or more nodes. The apparatus may be configured to transport 
one or more packets within a frame. The one or more nodes may be 
configured to add and/or drop at least one of the one or more 
packet from the frame. 

The objects, features and advantages of the present 
invention include providing a method and/or architecture for hybrid 
data transport that may (i) allow an add/drop multiplexer (ADM) 
and/or a router connected to a network to drop any type of protocol 
packet (such as ATM, IP, PPP, PDH (e.g., T1/T3) , or raw byte 
stream) from a payload area at any optical node, (ii) provide an 
ADM and/or a router connected to a network that may add any 
protocol packet (such as ATM, IP, PPP, PDH (e.g., T1/T3) , or raw 
byte stream) to the payload area at any optical node, either (a) as 
a new addition or (b) in place of a dropped packet, (iii) optimize 
available bandwidth of a network to deliver a maximum number of 
services and protocols and/or (iv) provide significant savings in 
equipment and fiber optics infrastructure. 
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Brief Description of the Drawings 

These and other objects, features and advantages of the 
present invention will be apparent from the following detailed 
description and the appended claims and drawings in which: 

FIG. 1 is a detailed timing diagram of conventional frame 
for fiber optic data transmission; 

FIG. 2 is a block diagram of a conventional multi-service 
optical network; 

FIG. 3 is a block diagram of various conventional 
*jl0 SONET/SDH add/drop multiplexers; 

FIG. 4 is a block diagram of a preferred embodiment of 
the present invention; 

FIG. 5 is a block diagram illustrating an implementation 

of the present invention; 

g 

15 FIG. 6 is a detailed block diagram of a protocol 

independent frame ; 

FIG. 7 is a detailed block diagram of a payload of FIG. 

6; 

FIG. 8 is a detailed block diagram of a packet of FIG. 7; 
2 0 FIG. 9 is a detailed block diagram of a packet header of 

FIG. 8; 
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FIG. 10 is a flow chart illustrating an operation of the 
present invention; 

FIG. 11 is a flow chart illustrating an operation of the 
present invention; and 

FIG. 12 is a flow chart illustrating an operation of the 
present invention. 

Detailed Description of the Preferred Embodiments 

Referring to FIG. 4, a block diagram of system 100 is 
shown in accordance with a preferred embodiment of the present 
invention. The system 100 may allow a single device to add and/or 
drop one or more types of data traffic from a single fiber optic 
line. The system 100 may provide an add/drop multiplexer (ADM) 
that may allow the use of a single device for a variety of data 
types. In one example, the system 100 may be implemented as a 
SONET/SDH network implementing SONET/SDH ADMs . The system 100 may 
require a single fiber optic line and a single type of SONET/SDH 
ADM to carry a number of different data traffic types. The system 
100 may result in significant savings for network carriers. 
Additionally, the system 100 may allow for provisioning services 
over short or long haul optical networks. 
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The structure of the network 100 may comprise a number of 
rings 102a-102n and a number of add/drop multiplexers (ADMs) 104a- 
104n. The ADMs 104a- 104n may be implemented to communicate with' 
the rings 102a-102n. Each of the rings 102a-102n may be 
implemented as an optical carrier ring. Each of the ADMs 104a- 104n 
may be configured to add/drop data (e.g., PDH data or IP data) 
to/from the network 100. In one. example, each of the ADMs 104a- 
104n may be implemented as a SONET/SDH ADM. The network 100 may — 
allow existing fiber optic lines to be utilized at full capacity. 
The system 100 may not require installation of additional fiber 
links (e.g., ADMs) for different types of data traffic. The system 
100 may allow conventional SONET/SDH ADMs to be implemented to 
add/drop data. The system 100 may not require additional SONET/SDH 
ADMs. Therefore, the system 100 may allow for significant cost 
savings in network infrastructure. 

In one example, the system 100 may be implemented as a 
long-haul multi -service network. In another example, the rings 
102a, 102b, 102c, 102d and 102n may be implemented as a customer 
premise equipment (CPE) ring, a local central office ring, an 
interexchange ring, a local central office ring and a CPE ring, 
respectively. However, the rings 102a- 102n may each be implemented 
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as another appropriate network component in order to meet the 
criteria of a particular implementation. Additionally, each of the 
rings 102a- 102n may be implemented to provide unified data 
transport . 

The system 100 may provide a simplified multi-service 
SONET/SDH network. The system 100 may provide unified data 
transport over a fiber optic line. The unified data transport may 
allow transportation of one or more different types of data over a 
single fiber optic line within a single SONET/SDH payload. The 
unified data transport may be provided by a data transport 
protocol. The data transport protocol may be implemented, in one 
example, as a hybrid data transport (HDT) . The HDT protocol may 
provide a common data header for all data types. The HDT protocol 
may create a frame having space for storing different types of data 
(to be discussed in connection with FIGS. 6, 7, 8 and 9). 
Additionally, the frame may be flexible in length in order to 
accommodate for different types and lengths of packet data. 

Referring to FIG. 5, a block diagram of an unified 
SONET/SDH network 12 0 is shown. The network 12 0 may support the 
hybrid data transport (HDT) protocol. The network 120 may comprise 
a ring 122 and a number of nodes 124a-124n. The nodes 124a-124n 
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may communicate with the ring 122 . In one example, the ring may be 
implemented as a single fiber optical line. Each of the nodes 
124a-124n may receive ATM cells, packet -over- SONET/SDH (POS) , and 
PDH (e.g., T1/T3) types of data via the ring 122. The nodes 124a- 
5 124n may be similar to the nodes 104a-104n. 

Referring to FIG. 6, a detailed block diagram of a — 
protocol independent frame 2 00 is shown. In one example, the frame 
P 200 may be implemented as a SONET/SDH frame. The frame 200 may 

01 illustrate mapping of different data types in a SONET/SDH SPE 

Bio envelope. The frame 200 may have an embedded frame header (and/or 
footer) 202 (e.g., a 32-bit frame header) to create a deterministic 
packet transport protocol. Additionally, the synchronous payload-7 



s 



U envelope SPE of frame 2 00 may comprise a number of 32 -bit payload 

O headers 204a-204n that may precede each packet of the envelope. 

□ 

15 The payload headers 204a-204n may proceed the packets regardless of 
a particular packet data type stored within the SPE. The frame 200-J 
may achieve bandwidth maximization. The frame header 2 02 may 
comprise a SONET/SDH path over-head (POH) 206. ^The SONET/SDH POH 
may comprise a single path signal label (PSL) value 208. The PSL 

20 value 208 may provide specific information regarding the various 
types of packets embedded within the payload of a particular frame. 

12 
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The PSL 208 may be implemented as a few header bits configured to 
denote the particular type of packet (e.g., ATM, IP, PPP, Frame 
Relay, etc.) embedded within the payload portion of the frame 200. 



SONET/ SDH synchronous payload envelope (SPE) of the frame 200 is 
shown. The SONET/SDH SPE may comprise a number of packets 22 0a- 
220n and a number of empty packets 222a-222n. The packet payload 
header 204a of the packet 220a may identify the packet /protocol . 
The packet payload header 204a may identify a packet type of the 
packet 220a stored (or transported) . The payload header 204a may 



tell what kind of packet/protocol (such as Ethernet, PPP, IP, Frame 
Relay, ATM cells, Tl, etc.) is inside a payload of the packet 220a. 
Different protocols may be supported at two ends (e.g., the devices 
104a- 104n) of a network without the need for provisioning in 
advance. In contrast, conventional approaches use a protocol over 
WAN, which is usually negotiated between two parties at the end 
devices 104a-104n of the WAN link. 

The payload header 2 04a may be used to tell whether one 
or more of the empty packets 222a-222n inside the SONET/SDH SPE 
that may be reused at an intermediate node. In contrast, in 
conventional SONET/SDH networks the entire SONET/SDH frame 2 00 

13 



Referring to FIG. 7, a detailed block diagram of the 
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travels around the ring until removed by the sender. With the 
system 100, a receiver may mark a portion of the SONET/SDH SPE of 
the frame 2 00 as reusable. A particular node on the fiber network 
100 may mark different sections of the SONET/SDH SPE as reusable by 
the same or remaining nodes 104a-104n. 

Provisioning of TDM channels may provide the ability to 
mark a portion (or many portions) of a SONET/SDH SPE payload area 
as reusable/non-reusable. With a non-reusable area, even when a 
receiver receives the packet, another receiver cannot reuse the 
packet area. However, the same receiver may reuse the reusable 
area. 

In general, there is no limit to the order and manner of 
packet positioning. Any packet may be marked in any fashion to 
support, for example, a dynamic mix of data and voice (TDM) traffic 
on a SONET/SDH network. Such an implementation is not possible 
with current technologies. The present invention may solve the 
problem of mixed value and data transmissions faced by telephone 
carriers and data providers. 

As SONET/SDH frames containing fixed bandwidth channels 
move around the ring, (i) intermediate nodes may detect reusable 
packets (e.g., the reusability bit is reset), (ii) note offsets of 
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the reusable packets, and (iii) preserve the respective offsets 
when recreating the frame (e.g., after adding packets from local 
input ports) for outbound traffic. 

Referring to FIG. 8, a detailed example of a packet is 
shown. An SDL framing 2 62 may be in the first 16 bits and may 
contain the length of the entire payload, including SDL framing 
bytes. A 16-bits of CRC-16 264 may be provided on the length field 
(e.g., xl6 + xl2 + x5 + 1) . The payload header 204a-204n may be a 
32 -bit word, followed optionally by an OAM bytes or MPLS labels 
268. MPLS/OAM bytes may be variable number of MPLS labels or OAM 
values that may be transmitted in the header area of HDT, outside 
of payload. A next fragment offset 2 70 may be a 16 -bit value 
showing the location offset of next packet fragment (if any) of the 
packet. The next fragment offset 270 is generally taken from the 
start of current packet. A header CRC 2 72 may be computed over 
payload header bytes only, with same scrambling polynomial used for 
SDL framing. A payload area 274 may contain the actual packet to 
be transmitted over the WDM or SONET/SDH link. The payload area 
2 74 may contain one of a number of types of protocol packets, such 
as Ethernet, ATM, GR.702, PPP, Frame Relay, etc. A payload CRC 276 
may be user- control led value and may be computed for the payload 
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bytes only. The payload CRC 276 is generally either a 16 or 32-bit 
value, depending on mutual negotiation between sending and 
receiving stations . 

Referring to FIG. 9, various parameters of the packet— 
header 2 04a are shown. The particular bit width of the payload 
header 2 04a may be varied accordingly to meet the design criteria 
of a particular implementation. A packet identifier 280 (e.g., D3 : 
DO) generally identifies the type of packet in the payload. For 
example, value of 0000 may represent a null packet. A null packet 
may indicate that the payload area may be reused. When a packet is 
dropped at a node, the length field does not generally need to be 
modified for the packet, only the D3 : DO bits need to be cleared. 

A header data area 282 may carry MPLS labels (e.g., 
outside of payload area) . Operation administration and maintenance 
(0AM) bytes 2 82 may be used for link management, or any other data 
separately from the payload. A reusability area 284 (e.g., D7) may 
be a "1" . If a SONET/SDH node can reuse a particular packet area, 
the packet length field 264 of the SDL header may give the size of 
the packet area. If the bit D7 may be set to a "0", then a node 
will not generally mark the packet area as re-usable, even after a 
packet has been dropped. The particular nodes of the various 
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configuration bits may be varied (e.g., inverted) accordingly to 
meet the design criteria of a particular implementation. 

A header length area 286 (e.g., D15: D8) may include, in 
one example, a 32 -bit payload header. A fragment identifier area 
5 288 (e.g., D17: D16) may be implemented as a two word value. 
Allowing packets to be at a fix location within the payload area 
and dropping/adding packets at intermediate nodes may require some 
gi packets to be fragmented to fill empty spaces left by previously 

ffl dropped packets. When a packet is fragmented, sections (e.g., 

§■9.0 fragments) of the packet may be stored in available spaces. The 
f£ fragments are linked by specifying a next-fragment location 

□ (offset) in the preceding fragment. A value of "00" in the first 

hk packet (fragment) may indicate that the payload area contains a 

CSiG 

M complete packet. A value of "01" may indicate the beginning packet 

15 of a fragmentation sequence. A value of "10" may indicate a 
continuation of packets. A value of «n» may mark the last 
fragment in the series. Other particular bit patterns may be 
implemented accordingly to meet the design criteria of a particular 
implementation. 

20 A padding area 290 (e.g., D18: D19) may indicate a 

minimum packet length. In one example, the minimum packet length 

17 
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may be 4 bytes (e.g., 2 bytes length + 2 bytes CRC) . Idle bytes at 
the end of packets and elsewhere may be marked by a length field of 
"0000" . In instances there may be less than 4 bytes left between 
packets. However, another appropriate number and/or configuration 
of bytes may be implemented in order to meet the criteria of a 
particular implementation. Additionally, the header structure may 
mandate the appropriate number of bytes. In this case, it may be 
impossible to place a SDL null packet. Such idle bytes are shown 
as tail-end padding for the preceding packet. An unused area 292 
(e.g., D31:20) may be used for additional expansion. 

Devices supporting the hybrid data transport (HDT) 
protocol may operate similarly to normal SONET/ SDH transport. 
Additionally, processing operations for ATM cells, POS, and PDH 
data may be similar. For example, the nodes 104a- 104n may operate 
similar to normal SONET/SDH nodes. Additionally, the HDT protocol 
may add a header to each frame 2 00 and add a payload header to each 
packet within a payload area of the SONET/SDH frame 200. The 
payload headers may allow the packets to mix within the payload 
area of the frame 200. Operation of the HDT protocol is generally 
related to processing of the headers. The processing of the 
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headers may identify a type of data packet within the SONET/SDH 
payload. The packet may be one of a plurality of packet types. 

Recall that support of PDH-type (T1/T3) channel may 
require a fixed starting location for the channel in every frame. 
If PDH support is not required (e.g., no fixed bandwidth channels) , 
packets of any data type may be placed anywhere within the 
envelope. The placement of the packets of various data types 
within the SPE may allow the system 100 to achieve excellent 
bandwidth utilization. Additionally, the system 100 may have a 
reduced operational complexity. If PDH support is required (e.g., 
fixed bandwidth channels) , the fixed bandwidth channels may be 
required to be static in their locations for each consecutive 
SONET/SDH frame. In this case, any additionally added data packets 
(e.g., ATM or IP) may need to be fragmented to fit the empty spaces 
left by dropped packets. 

However, fragmentation of a packet may be easily 
accomplished with the system 100. The network 100 sequentially 
transmit bytes in the payload area of the frame 200. Since packet 
bytes are always sent in sequence on a particular optical link, a 
plain offset for the next fragment starting location may link 
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packet fragments. The system 100 may efficiently recover the 
sequenced fragments. 

Referring to FIG. 10, an example of a receive operation 
300 is shown. A node may receive a frame (e.g., the nodes 104a- 
104n) . A block 302 may determine if the received frame is an HDT 
frame. The block 3 02 may use a PSL value in the POH to determine 
the type of protocol carried inside the SPE. If the PSL shows POS, 
ATM, or PDH traffic, the receive operation may proceed to the block 
304. If no HDT packets are present, a block 306 may process the 
POS/ATM/PDH packet. If in the block 302, the PSL shows the SPE 
contains HDT frames, the node may implement additional logic for 
HDT processing. The HDT logic may detect and route different types 
of packets embedded in the SONET/SDH SPE. 

A block 3 08 may read the POH. A block 310 may determine 
a first packet of the SONET/SDH SPE. A block 312 may read a length 
and CRC of the first packet. A block 314 may determine a match of 
the length and the CRC. If a non-match of the length and CRC 
occurs, the receive operation is generally continues to a block 
316. The block 316 may read a next word of the packet. If a match 
occurs, the receive operation may process the packet. Once the 
payload header has been processed and different packet types are 

20 
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identified, hardware (e.g., implemented in the system 100) may use 
header fields to retrieve the payload and implement hardware blocks 
for processing. 

In traditional ATM transport over SONET/SDH, looking at 
the PSL value generally retrieves ATM cells. The PSL may determine 
if ATM cells are present and may then reach the SONET/SDH SPE to 
retrieve the fixed byte ATM cells, either with or without HEC-based 
cell delineation. 

In HDT transport protocol, if the payload header in the 
HDT shows that the payload contains ATM cells, the hardware device 
may retrieve the appropriate payload bytes (up to number of bytes 
specified in length field) and sends the byte stream to an existing 
ATM cell processing block. The ATM cell processing block may then 
work on the byte stream using HEC hunting just as if the SPE 
contained only ATM cells in the payload area. 

The ADMs may be implemented to provide the receive 
operation 300. The receive operation 300 may illustrate a drop 
operation of the SONET/SDH ADMs 104a- 104n. Each node on a network 
may receive a SONET/SDH frame. The nodes may use the PSL value in 
the POH to determine a type of protocol carried inside the 
SONET/SDH SPE. If the PSL shows POS, or ATM, or PDH traffic, the 
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nodes may receive the packet normally. If the PSL shows the 
SONET/SDH frame contains SONET/SDH HDT frames, the nodes may 
implement additional logic for HDT processing. The additional HDT 
processing may detect and route different types of packets embedded 
in the SONET/SDH SPE . Generally, once the payload header has been 
processed and different packet types are identified, the hardware 
may use header fields to retrieve the payload and implement normal 
processing techniques . 

Referring to FIG. 11, an example of a processing 
operation 350 is shown. The processing operation 350 may 
illustrate packet processing using the HDT protocol. The 
processing operation 350 may include dropping a packet of data from 
an envelope and returning the frame back to the network 100. 
Additionally, the processing operation 3 50 may reroute remaining 
data of the SONET/SDH frame for onward transmission to downstream 
nodes . 

A device supporting the hybrid data transport (HDT) 
protocol generally operates much the same as a normal SONET/SDH 
device would operate. Operations for processing ATM cells, POS, 
and PDH protocols may be similar. The HDT protocol generally adds 
a header to each frame and a payload header to each packet to allow 
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mixing within the same SPE. Much of the HDT processing is 
generally related to processing of the headers in order to identify 
the type of packet. Once a type of packet is identified, starting- 
address of data bytes may be passed to standard logic blocks (e.g., 
ATM, PDH, POS, SRP and Ethernet processing blocks) for processing 
an individual packet type . f 

As the frame is received initial bytes may be placed in 
a small transit buffer. If the packet does not belong to the 
receiving node, the bytes are generally streamed out of transit 
buffer to an output port. However, if the packet belongs to the 
node processing may continue. 

A block 352 may read a payload length and payload header 
of an incoming packet. If a bandwidth allocate bit (e.g., BA - bit 
D7) is asserted "1" in the payload header (PH) , the packet area may 
be reserved for fixed bandwidth channels such as PDH. To provide 
fixed bandwidth the node may place an outgoing packet at a same 
offset of the payload SPE when transmitting. 

A block 354 may determine a reusability of the packet. 
If the bandwidth bit D7 is "0", the node may clear the packet 
identifier bits D3 : DO to mark the packet as void or reusable. A 
reusable packet may proceed to the block 356. If the packet area 
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is reserved, the packet identifier bits (e.g., D3 : DO) may not be 
cleared. If the bytes of the packet belong to the receiving node, 
the packet may be sent to the system via the processing operation 
350. A particular number of bytes to be sent to the system is 
generally specified in the length field of the SDL header. If the 
header shows fragmentation, then the packet is generally received 
and assembled before being sent to system. 

Referring to FIG. 12, an example of a transmit operation 
400 is shown. Transmission involves addition of new data from 
system or retransmission of circulating data from upstream nodes to 
downstream nodes. A device supporting HDT may receive a packet to 
be transmitted from a system side. In the transmit operation 400, 
a node may take inputs from different sources 402, encapsulate the 
packets with an SDL length/CRC fields 404, add an HDT header 406 to 
each of the packets, and then store the packets inside the SPE. 

The node may not send a fresh frame on the network in 
order to transmit the packets. A TDM channel check 408 may 
determine a reusability of the SPE. The transmit operation 400 may 
reuse available space in an incoming SONET/SDH frame (containing 
HDT frames) . The transmit operation 400 may then may proceed to a 
length check 410 to see if there is any space available in the SPE 



0325.00371 
CD00064 

to insert the packet to be sent. If there is enough space, the 
entire packet is stored (with proper SDL framing and HDT header 
bytes) . Any remaining bytes, depending on the size, are generally 
either (i) filled with a null HDT packet (e.g., the payload header 
identification bits are 0000) , (ii) filled with SDL null packets 
(e.g., pairs of length/CRC with a null length field), or (iii) 
accounted for as tail-end padding (e.g., if the size is less than 
4 bytes) . 

If the transmit operation 400 runs into a fixed-bandwidth 
channel allocation midway through the packet allocation, the packet 
is generally fragmented. In this case, a portion of the packet may 
be stored at one place and other fragments may be stored at another 
free location. The first fragment offset pointer may contain the 
starting location of second fragment. Since bytes are transmitted 
sequentially in the frame 2 00, reassembling fragments may be easily 
achieved. 

If a particular node detects an incoming SONET/SDH frame 
on a receive port, or if there is a frame in the transmit/receive 
queue, the node may check the SONET/ SDH frame 2 00 to see if there 
are unused/reusable areas in the incoming/queued frame that can be 
used for sending data. If there is enough space available in the 
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frame, the node may fill the space with additional data before 
sending the frame . 

In HDT, PDH channels of any bandwidth (up to allowable 
SONET bandwidth limits) may be provisioned anywhere inside the 
SONET/SDH SPE. To achieve precise timing, PDH bytes must begin at 
the same offset inside the SONET/SDH SPE. However, allocation of 
PDH channels at different locations inside a SONET/SDH SPE may 
create fragments of unused bytes all over the SONET/SDH SPE. For 
efficient transport of variable-size IP packets, these unused bytes 
may be utilized for IP data. 

The transmit (e.g., add) operation 400 may receive inputs 
from different sources. The operation 4 00 may (i) add an HDT 
header to each outgoing packets, (ii) encapsulate the packets with 
SDL length/CRC fields and (iii) place the packets within a SPE of 
a SONET/SDH frame. The SONET/SDH node may not be required to send 
a fresh frame on the network. The SONET/SDH node may be configured 
to reuse available space in an incoming HDT protocol frame. 

For example, a device (e.g., ADM or router) supporting 
HDT may receive a packet from a system side that may transmit. The 
device may then look in an output packet buffer to determine if 
there is any space available where the packet may be inserted. If 





0325.00371 
CD00064 

there is enough space, the entire packet may be stored (with proper 
SDL framing and HDT header bytes) . Any remaining bytes, depending 
on the size may be either filled with a null HDT packet (the 
payload header identification bits are 0000) , filled with SDL null 
packets (pairs of length/CRC with a null length field) or (if the 
size is less than 4 bytes) accounted for as tail-end padding. 

If the device encounters a fixed-bandwidth channel 
allocation midway through packet allocation, the device may 
fragment the packet. A portion of the packet may be stored at one 
location, while other fragments may be stored at another free 
location. The first fragment may have an offset pointer that may 
contain a starting location of the second fragment. Since, data 
bytes may be transmitted sequentially in a SPE, reassembling the 
fragments may not be difficult. 

The packets may be added either using a fresh SONET/SDH 
SPE or by reusing bytes inside an incoming or a previously 
created/queued frame. The decision of which packet to add to a 
void or reusable packet area inside an SPE may be determined by one 
or more of the following rules: 

(i) pick a type of packet that may be specified by the 
user for an add operation at the node; 
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(ii) pick a packet (or a collection of packets) that may 
fit inside the reusable area; 

(iii) of all packets that may fit inside the reusable 
space, pick one based on QoS parameters or packet priority. Since 
SONET/SDH frames repeat at 125|iS an .interval, frequency of packet 
transmission within the SPE may be adjusted to achieve desired 
transfer rates easily; 

(iv) for the packet, if bandwidth is generally to be 
reserved, program the bandwidth allocation bit (bit D7) so all 
downstream nodes may set a fixed bandwidth for the packet; 

(v) set the payload identifier bits (D3 : DO) to indicate 
a type of packet. If any MPLS labels may be added, add them before 
the packet and mark the length value in the payload header; 

(vi) create a SDL length/CRC construct, prepare a 
complete packet and add the packet to the payload area; and 

(vii) if the node detects an incoming SONET/SDH frame on 
the receive port, or if there is a frame in the transmit/receive 
queue, the node may check the frame • to see if there are 
unused/reusable areas in the incoming/queued frame that may be used 
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for sending data. If there is enough space available in the frame, 
the node may fill the space with data. 

The system 100 may allow a SONET/ SDH add/drop multiplexer 
(ADM) or a router connected to SONET/SDH ring to drop any type of 
protocol packet (such as ATM, IP, PPP, PDH such as T1/T3, or a raw 
byte stream) at any optical node. The system 100 may allow a 
SONET/ SDH ADM or a router connected to SONET/ SDH ring to add any 
protocol packet (such as ATM, IP, PPP, PDH such as T1/T3, or a raw 
byte stream) to a SONET/SDH payload area at any optical node. The 
packet may be added either as (i) a new addition or (ii) in place 
of a dropped packet . 

The system 100 may allow a user to optimize available 
bandwidth of the SONET/ SDH network to deliver maximum number of 
services and protocols using same single fiber. The system 100 may 
provide significant savings in equipment and fiber optics 
infrastructure. 

While the invention has been particularly shown and 
described with reference to the preferred embodiments thereof, it 
will be understood by those skilled in the art that various changes 
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in form and details may be made without departing from the spirit 
and scope of the invention. 
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